Skip to content

refactor: simplify switch and improve locking in ClusterRendererMultipleItems #1557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dkhawk
Copy link
Contributor

@dkhawk dkhawk commented Aug 6, 2025

  • Replaced a traditional switch statement with an enhanced switch expression in setAnimationType.
  • Added a setAnimationInterpolator method to allow custom interpolators.
  • Ensured lock.unlock() is always called in finally blocks within MarkerModifier and AnimationTask for better resource management.
  • Added @Override annotation to ViewModifier.run().

…pleItems

- Replaced a traditional switch statement with an enhanced switch expression in `setAnimationType`.
- Added a `setAnimationInterpolator` method to allow custom interpolators.
- Ensured `lock.unlock()` is always called in `finally` blocks within `MarkerModifier` and `AnimationTask` for better resource management.
- Added `@Override` annotation to `ViewModifier.run()`.
@dkhawk dkhawk requested a review from kikoso August 6, 2025 00:43
@googlemaps-bot
Copy link
Contributor

Code Coverage

Overall Project 34.37% -0.93% 🍏
Files changed 0%

File Coverage
ClusterRendererMultipleItems.java 0% -8.19%

}

public void setAnimationInterpolator(TimeInterpolator interpolator) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Being this a public method, worth considering adding a line of documentation to explain that it sets the Interpolator for the current animation.

@kikoso
Copy link
Collaborator

kikoso commented Aug 6, 2025

Would it make sense to add some of this changes (namely, overriding the run method and moving the lock.unlock within a try / finally block? We have the same in the other renderers.

Besides that, this changes make sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants